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ABSTRACT 

Computing  is  moving  toward  a  pervasive  context-aware  en¬ 
vironment  in  which  agents  with  limited  resources  will  re¬ 
quire  external  support  to  help  them  become  context-aware. 
In  this  paper,  we  describe  an  agent  based  architecture  called 
Context  Broker  Architecture  (CoBrA)  to  help  these  agents 
to  acquire,  reason  about  and  share  context  knowledge.  A 
key  component  in  our  architecture  is  an  explicit  context  on¬ 
tology  defined  using  the  Web  Ontology  Language  (OWL). 
This  ontology  models  the  basic  concepts  of  people,  agents, 
places,  and  presentation  events.  We  also  describe  a  use  case 
scenario  and  prototype  design  of  CoBrA  in  an  intelligent 
meeting  room  environment. 

1.  INTRODUCTION 

Pervasive  computing  is  a  vision  for  the  near  term  future  in 
which  devices,  services,  and  software  agents  will  seamlessly 
integrate  and  cooperate  in  support  of  human  objectives  - 
anticipating  our  needs,  negotiating  for  services,  acting  on 
our  behalf,  and  delivering  services  in  an  anywhere,  any-time 
fashion.  To  realize  this  vision,  an  important  next  step  is 
the  development  of  an  infrastructure  that  can  help  ubiq¬ 
uitous  agents,  services,  and  devices  become  aware  of  their 
contexts  (including  the  ability  to  reason  about  and  to  share 
this  knowledge) .  We  are  developing  a  new  pervasive  context- 
aware  computing  infrastructure  called  Context  Broker  Ar¬ 
chitecture  (CoBrA)  [3]  that  will  help  agents  behave  in  an 
intelligent,  context-aware  manner. 

By  context,  we  mean  an  understanding  of  a  location, 
its  environmental  attributes  (e.g.,  room  temperature,  noise 
level,  and  light  intensity),  and  the  people,  devices,  objects, 
and  software  agents  it  contains.  This  understanding  neces¬ 
sarily  extends  to  modeling  the  activities  and  tasks  that  are 
taking  place  in  a  location  as  well  as  the  beliefs,  desires,  com¬ 
mitments,  and  intentions  of  the  human  and  software  agents 
involved. 

In  the  past,  a  number  of  distributed  systems  have  been 
developed  with  a  common  goal  to  support  pervasive  com¬ 
puting  (e.g.,  Intelligent  Room  [5],  Context  Toolkit  [16],  and 
Cooltown  [12]).  Although  the  research  of  these  systems 
have  made  tremendous  progress  in  advancing  pervasive  com¬ 
puting,  the  resulting  implementations,  however,  have  weak¬ 
nesses  in  supporting  knowledge  sharing  and  context  reason¬ 
ing  due  to  lacking  an  explicit  representation  of  context  on- 

*This  work  was  partially  supported  by  DARPA  contract 
F30602-97-1-0215,  Hewlett  Packard,  NSF  award  9875433, 
and  NSF  award  0209001. 


tologies  [3,  4]. 

An  explicit  representation  of  ontology  consists  of  a  formal 
model  of  vocabularies  (i.e.,  classes  and  properties)  and  as¬ 
sociated  semantics  (i.e.,  the  relationships  between  different 
classes  and  properties).  Without  a  well-defined  ontology, 
knowledge  sharing  and  context  reasoning  is  often  difficult  in 
the  previous  systems  [3]. 

In  the  previous  systems,  ontologies  are  often  defined  based 
on  ad  hoc  representation  schemes  such  as  a  set  of  program¬ 
ming  language  objects  or  data  structures.  There  are  two 
problems  with  this  approach:  (i)  the  use  of  ad  hoc  represen¬ 
tation  schemes  lacking  shared  vocabularies  can  hinder  the 
ability  of  independently  developed  agents  to  interoperate 
(i.e.,  to  share  context  knowledge),  and  (ii)  the  use  of  ob¬ 
jects  and  data  structures  of  low  expressive  power  provides 
inadequate  support  for  context  reasoning. 

In  order  to  help  agents  to  discover,  reason  about  and  com¬ 
municate  contextual  information,  we  must  define  explicit 
ontologies  for  context  concepts  and  knowledge.  In  this  pa¬ 
per,  we  present  a  set  of  ontologies  that  we  have  developed 
to  support  ubiquitous  agents  in  the  CoBrA  system.  Our 
ontology  (CoBrA  ontology)  is  defined  using  the  Web  Ontol¬ 
ogy  Language  (OWL)  [18],  an  Semantic  Web  language  be¬ 
ing  specified  by  the  W3C.  The  current  version  of  the  CoBrA 
ontology  models  the  basic  concepts  of  people,  agents,  places 
and  presentation  events.  It  also  describes  the  properties  and 
relationships  between  these  basic  concepts  including  (i)  rela¬ 
tionships  between  places,  (ii)  roles  associated  with  people  in 
presentation  events,  and  (iii)  typical  intentions  and  desires 
of  speakers  and  audience  members. 

The  rest  of  this  document  is  structured  into  nine  sections. 
In  the  next  section,  we  briefly  review  the  Semantic  Web  and 
the  OWL  language.  In  Section  3,  we  describe  the  key  fea¬ 
tures  of  CoBrA  and  its  design  rationale.  In  Section  4,  we 
present  a  typical  use  case  scenario  of  the  CoBrA  system  and 
point  out  how  CoBrA  can  help  agents  to  reason  about  con¬ 
texts  and  share  knowledge.  After  our  discussion,  in  Section 
5,  we  describe  the  key  ontology  concepts  in  the  latest  version 
of  our  CoBrA  ontology.  In  Section  6,  a  prototype  system  de¬ 
sign  of  the  Context  Broker  Architecture  is  presented.  A  brief 
discussion  of  related  work  and  some  concluding  comments 
are  given  in  Section  7  and  Section  8,  respectively. 

2.  THE  SEMANTIC  WEB  AND  OWL 

Semantic  Web  is  a  vision  of  the  next  generation  World 
Wide  Web  in  which  information  is  given  well-defined  mean¬ 
ing,  better  enabling  computers  and  people  to  work  in  coop¬ 
eration  [2] .  Research  on  the  Semantic  Web  is  driven  by  the 
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need  for  a  new  knowledge  representation  framework  to  cope 
with  the  explosion  of  unstructured  digital  information  on 
the  existing  Web.  Current  Semantic  Web  research  focuses 
on  the  development  of  ontology  languages  and  tools  for  con¬ 
structing  digital  information  that  can  be  “understood”  by 
computers  [2]. 

The  origin  of  the  Semantic  Web  research  goes  deep  in 
the  roots  of  Artificial  Intelligent  research  (e.g.,  knowledge 
representation  and  ontology).  However,  the  recent  pub¬ 
licly  known  Semantic  Web  research  begins  with  the  DAML 
(DARPA  Agent  Markup  Language)  effort  in  the  US1  and  the 
OIL  (Ontology  Inference  Layer)  effort  in  Europe2.  In  late 
2000,  the  original  DAML  language  is  combined  with  many 
of  the  ontology  modeling  features  from  the  OIL  language, 
and  the  result  is  the  DAML+OIL  language. 

In  late  2001,  the  World  Wide  Web  Consortium  (W3C)  es¬ 
tablished  the  Web  Ontology  Working  Group  with  the  goal  of 
introducing  Semantic  Web  technologies  to  the  main  stream 
web  community.  The  group  has  specified  a  language  OWL 
that  is  based  on  DAML+OIL  and  shares  many  of  its  features 
(e.g.,  using  RDF  as  the  modeling  language  to  define  onto¬ 
logical  vocabularies  and  using  XML  as  the  surface  syntax 
for  representing  information  [18]). 

We  have  chosen  to  define  our  ontology  for  contexts  for 
three  reasons.  First,  it  is  much  more  expressive  than  RDF 
or  RDF-S  allowing  us  to  build  more  knowledge  into  the  on¬ 
tology.  Second,  we  chose  to  use  OWL  over  DAML+OIL 
because  OWL  has  been  designed  as  a  standard  and  has  the 
backing  of  a  well  known  and  regarded  standards  organiza¬ 
tion.  Third,  from  a  system  implementation  point  of  view, 
the  emergence  of  ontology  inference  engines  in  support  for 
the  OWL  language  (e.g.,  FaCT  [9],  RACER  [19]  and  Bubo 
[20])  leads  us  to  believe  adopting  OWL  will  create  new  op¬ 
portunities  for  building  more  advanced  intelligent  systems. 
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Figure  1:  An  intelligent  context  broker  acquires  con¬ 
text  information  from  devices,  agents  and  sensors  in 
its  environment  and  fuses  it  into  a  coherent  model 
that  is  then  shared  with  the  devices  and  their  agents. 


nize  context  knowledge,  enabling  fault-tolerance  (similar  to 
the  persistent  broker  team  described  in  [13]). 

In  an  intelligent  space,  the  primary  responsibilities  of  a 
broker  are  to  (i)  acquire  context  information  from  hetero¬ 
geneous  sources  and  reason  about  this  information  to  main¬ 
tain  a  consistent  context  model,  (ii)  help  distributed  agents 
to  share  context  knowledge  through  the  use  of  common  on¬ 
tologies,  agent  communication  languages  and  protocols,  and 
(iii)  protect  the  privacy  of  users  by  establishing  and  enforc¬ 
ing  user-defined  policies  while  sharing  sensitive  personal  in¬ 
formation  with  agents  in  the  community. 

A  context  broker  has  four  main  functional  components: 


3.  CONTEXT  BROKER  ARCHITECTURE 

CoBrA  is  an  agent  based  architecture  for  supporting 
context-aware  computing  in  intelligent  spaces.  Intelligent 
spaces  are  physical  spaces  (e.g.,  living  rooms,  vehicles,  cor¬ 
porate  offices  and  meeting  rooms)  that  are  populated  with 
intelligent  systems  that  provide  pervasive  computing  ser¬ 
vices  to  users  [11]. 

Central  to  our  architecture  is  the  presence  of  an  intelligent 
context  broker  (or  broker  for  short)  that  maintains  and  man¬ 
ages  a  shared  contextual  model  on  the  behalf  of  a  community 
of  agents.  These  agents  can  be  applications  hosted  by  mo¬ 
bile  devices  that  a  user  carries  or  wears  (e.g.,  cell  phones, 
PDAs  and  headphones),  services  that  are  provided  by  de¬ 
vices  in  a  room  (e.g.,  projector  service,  light  controller  and 
room  temperature  controller)  and  web  services  that  provide 
a  web  presence  for  people,  places  and  things  in  the  physical 
world  (e.g.,  services  keeping  track  of  people’s  and  objects’ 
whereabouts  [12]). 

In  a  large-scale  intelligent  space  (e.g.,  a  campus  or  a  build¬ 
ing),  multiple  brokers  can  form  a  broker  federation.  Indi¬ 
vidual  broker  in  a  federation  is  responsible  for  managing 
parts  of  the  intelligent  space  (e.g.,  a  room  in  a  particular 
building).  Brokers  are  related  to  each  other  in  some  orga¬ 
nizational  structure  (e.g.,  peer-to-peer  or  hierarchical)  in  a 
federation,  and  they  can  periodically  exchange  and  synchro- 

XDAML  web  site:http : //www .  daml .  org 

2OIL  web  site:  http://www.ontoknowledge.org/oil/ 


1.  Context  Knowledge  Base:  a  persistent  store  for 
context  knowledge  in  an  intelligent  space.  This  knowl¬ 
edge  base  provides  a  set  of  API’s  for  other  components 
to  assert,  delete,  modify,  and  query  stored  knowledge. 

2.  Context  Reasoning  Engine:  a  reactive  inference 
engine  that  reasons  over  the  knowledge  base.  Its  main 
function  is  to  deduce  additional  knowledge  from  infor¬ 
mation  acquired  from  external  sources  and  to  maintain 
the  consistency  of  the  knowledge  base. 

3.  Context  Acquisition  Module:  a  collection  of  pre¬ 
defined  procedures  for  acquiring  information  from  the 
external  sources.  It  serves  as  a  middleware  abstrac¬ 
tion  for  acquiring  contexts  from  heterogeneous  sources 
(e.g.,  physical  sensors,  web  services,  databases,  devices 
and  agents). 

4.  Privacy  Management  Module:  a  set  of  communi¬ 
cation  protocols  and  behavior  rules  that  the  broker  fol¬ 
lows  when  performing  privacy  management  tasks  (i.e., 
negotiate  privacy  policies  with  new  users  and  enforcing 
these  policies  when  sharing  information  with  agents  in 
the  community). 

4.  ONTOLOGIES  IN  COBRA 

In  a  pervasive  computing  environment,  individual  agents 
may  have  limited  resources  to  acquire,  reason  about  and 
share  contexts.  In  CoBrA,  the  role  of  a  broker  is  to  help 


these  resource- limited  agents  -  e.g.,  to  reason  about  contexts 
and  share  context  knowledge. 

In  the  next  two  sections,  we  will  describe  a  typical  multi- 
agent  scenario  of  CoBrA  (Section  4.1)  and  point  out  how 
explicitly  represented  ontologies  enable  knowledge  sharing 
and  context  reasoning  (Section  4.2). 

4.1  An  Intelligent  Meeting  Room  Scenario 

R210  is  an  intelligent  meeting  room  with  RFID  sensors3 
embedded  in  the  walls  and  furniture  for  detecting  the  pres¬ 
ence  of  the  users’  devices  and  clothing.  As  Alice  enters  the 
room,  these  sensors  inform  the  R210  broker  that  a  cell  phone 
belonging  to  her  is  present  and  the  broker  adds  this  fact  in 
its  knowledge  base. 

As  she  sits,  the  agent  on  Alice’s  Bluetooth  enabled  cell 
phone  discovers  R210’s  broker  and  engages  in  a  “hand 
shake”  protocol  (e.g.  authenticates  agent  identities  and  es¬ 
tablishes  trust  [10])  after  which  it  informs  the  broker  of  Al¬ 
ice’s  privacy  policy.  This  policy  represents  Alice’s  desires 
about  what  the  broker  should  do  and  includes  (i)  the  con¬ 
text  information  about  Alice  that  the  broker  is  permitted 
or  prohibited  from  storing  and  using  (e.g.,  yes  to  her  lo¬ 
cation  and  roles,  no  to  the  phone  numbers  she  calls),  (ii) 
other  agents  that  the  broker  should  inform  about  changes 
in  her  contextual  information  (e.g.,  keeping  Alice’s  personal 
agent  at  home  informed  about  her  location  contexts),  and 
(iii)  the  permissions  for  other  agents  to  access  Alice’s  con¬ 
text  information  (e.g.,  all  agents  in  the  meeting  room  can 
access  Alice’s  contexts  while  she  is  in  the  room). 

After  receiving  Alice’s  privacy  policy,  the  broker  creates  a 
profile  for  Alice  that  defines  rules  and  constraints  the  broker 
will  follow  when  handling  any  context  knowledge  related  to 
Alice.  For  example,  given  the  above  policy,  the  profile  for 
Alice  would  direct  the  broker  (i)  to  acquire  and  reason  about 
Alice’s  location  and  activity  contexts,  (ii)  to  inform  Alice’s 
personal  agent  at  home  when  Alice’s  contexts  change,  and 
(iii)  to  share  her  contexts  with  agents  in  the  meeting  room. 

Knowing  Alice’s  cell  phone  is  currently  in  R210  and  hav¬ 
ing  no  evidence  to  the  contrary,  the  broker  concludes  Alice 
is  also  there.  Additionally,  because  R210  is  a  part  of  the  En¬ 
gineering  building,  which  in  turn  is  a  part  of  the  Campus, 
the  broker  concludes  Alice  is  located  in  Engineering  building 
and  on  campus.  These  conclusions  are  asserted  into  broker’s 
knowledge  base. 

Following  the  profile,  the  broker  informs  Alice’s  personal 
agent  of  her  whereabouts.  On  receiving  this  information 
about  Alice,  her  personal  agent  attempts  to  determine  why 
Alice  is  there.  Her  Outlook  calendar  has  an  entry  indicating 
that  she  is  to  give  a  presentation  on  Campus  about  now,  so 
the  personal  agent  concludes  that  Alice  is  in  R210  to  give 
her  talk  and  informs  the  R210  broker  of  it’s  belief. 

On  receiving  information  about  Alice’s  intention,  the 
R210  broker  shares  this  information  with  the  projector  agent 
and  the  lighting  control  agent  in  the  ECS  210.  Few  minutes 
later,  the  projector  agent  downloads  the  slides  from  Alice’s 
personal  agent  and  sets  up  the  projector,  the  lighting  control 
agent  dims  the  room  lights. 

4.2  Knowledge  Sharing  &  Context  Reasoning 

An  explicit  representation  of  ontologies  can  be  used  to  en¬ 
able  knowledge  sharing  and  provide  a  means  for  reasoning. 

3RFID  stands  for  Radio  Frequency  Identification  (see  also 
http : / /www . rf id . org) 


In  the  scenario  above,  three  distinct  but  related  types  of  con¬ 
text  information  are  used:  (i)  location  contexts  (“Where  is 
Alice?”),  (ii)  activity  context  (“What  is  she  doing?”),  and 

(iii)  agent  contexts  (“What  might  she  want  to  do  in  this 
context?”).  Note  that  an  understanding  of  these  contexts 
is  only  possible  because  of  all  different  types  of  agents  (in¬ 
cluding  sensors  and  devices)  share  information  with  each 
other  using  common  ontologies,  and  the  broker  is  able  de¬ 
rive  additional  information  about  Alice’s  location  because  it 
has  a  model  of  the  rooms  and  buildings  involved  and  has  a 
rudimentary  model  of  spatial  relationships. 

Context  reasoning  may  also  take  place  in  detecting  in¬ 
consistent  beliefs  about  certain  contexts.  For  example,  in  a 
pervasive  computing  environment,  information  sensed  from 
the  physical  world  can  be  both  noisy  and  ambiguous  (e.g., 
sensors  may  report  that  the  same  person  is  present  in  two 
different  room  at  the  same  time).  With  ontologies,  it  is  pos¬ 
sible  to  guide  the  context  reasoning  process  to  detect  and 
resolve  this  inconsistent  knowledge  (e.g.,  in  our  CoBrA  on¬ 
tology,  containment  relationships  between  different  classes 
of  locations  can  be  used  to  detect  this  type  of  knowledge 
inconsistency). 

5.  THE  COBRA  ONTOLOGY 

This  section  describes  key  ontology  concepts  in  the  cur¬ 
rent  version  of  the  CoBrA  ontology  (v0.2)4.  This  ontology 
defines  a  vocabulary  for  describing  people,  agents,  places 
and  presentation  events  for  supporting  an  intelligent  meet¬ 
ing  room  system  on  a  university  campus.  It  also  defines  a 
set  of  properties  and  relationships  that  are  associated  with 
these  basic  concepts. 

Figure  2  shows  a  complete  list  of  the  names  of  the  classes 
and  properties  in  the  CoBrA  ontology.  In  v0.2,  there  are  41 
classes  (i.e.,  RDF  resources  that  are  type  of  owl: class)  and 
36  properties  (i.e.,  RDF  resources  that  are  type  of  either 
owl :  ObjectProperty  or  owl  :DatatypeProperty).  These 
ontologies  are  expressed  using  the  OWL/XML  syntax  [17]. 

Our  ontology  is  categorized  into  four  distinctive  but  re¬ 
lated  themes:  (i)  concepts  that  define  physical  places  and 
their  associated  spatial  relations  (e.g.,  containment,  social 
and  organizational  properties)5,  (ii)  concepts  that  define 
agents  (i.e.,  both  human  agents  and  software  agents)  and 
their  associated  attributes,  (iii)  concepts  that  describe  the 
location  contexts  of  an  agent  on  a  university  campus,  and 

(iv)  concepts  that  describe  the  activity  contexts  of  an  agent, 
including  the  roles  of  speakers  and  audiences  and  their  asso¬ 
ciated  desires  and  intentions  in  a  presentation  event.  In  the 
rest  of  this  section,  we  discuss  each  of  these  four  themes. 

5.1  Places 

The  notion  of  a  place  in  CoBrA  is  presently  restricted  to 
a  set  of  physical  locations  that  are  typically  found  on  a  uni¬ 
versity  campus.  These  locations  include  campus,  building, 
room,  hallway,  stairway,  restroom,  and  parking  lot.  These 
physical  locations  are  all  assumed  have  well-defined  spatial 
boundaries  (e.g.,  all  locations  can  be  uniquely  identified  by 
geographical  coordinates  -  longitude  and  latitude).  In  addi¬ 
tion,  all  locations  on  a  university  campus  have  identifiable 

4 A  complete  version  of  the  ontology  is  available  at  http: 
//daml .umbc . edu/ ontologies/cobra/0 . 2/ cobra- ont 
5In  v0.2,  only  containment  relations  are  defined,  additional 
properties  will  be  included  in  the  next  version  of  the  ontol¬ 
ogy- 
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Figure  2:  A  complete  list  of  the  names  of  the  classes  and  properties  in  the  CoBrA  ontology  (v0.2). 


string  names  that  are  assigned  to  them  by  some  official  bod¬ 
ies  (e.g.,  by  the  university  administration). 

When  modeling  physical  locations,  we  define  a  class  called 
Place  which  generalizes  all  type  of  locations  on  a  campus. 
This  abstract  class  defines  a  set  of  properties  that  are  com¬ 
mon  to  all  concrete  physical  location  classes,  which  consists 
of  longitude, latitude  and  hasPrettyName. 

Place  classes  (including  subclasses)  participate  in  con¬ 
tainment  relations.  These  relationships  are  defined  by  two 
related  object  properties6  called  spatiallySubsumes  and 
isSpatiallySubsumedBy.  The  former  describes  the  subject 
of  this  property  spatially  subsumes  the  object  of  this  prop¬ 
erty  (e.g.,  a  building  spatially  subsumes  a  room  in  the  build¬ 
ing),  and  the  latter  describes  the  subject  of  this  property  is 
spatially  subsumed  by  the  object  of  this  property  (e.g.,  a 
room  in  the  building  is  spatially  subsumed  by  the  building). 
In  the  context  of  the  OWL  language,  these  two  properties 
are  defined  as  an  inverse  property  of  each  other. 

Note  that  in  the  current  version  of  the  ontology,  the  do¬ 
main  and  the  range  of  both  spatiallySubsumes  and  is¬ 
SpatiallySubsumedBy  properties  are  of  the  class  type  Place. 
In  other  word,  these  two  properties  cannot  be  used  to  make 
statements  about  the  containment  of  a  person,  agent  or  ob¬ 
ject  in  a  physical  place.  In  Section  5.2,  we  will  describe 
alternative  constructs  for  expressing  this  type  of  statements. 

In  addition  to  containment  relationships,  physical  places 
may  also  have  events  and  activities  associated  with  them 
(e.g.,  a  meeting  may  be  taken  place  in  a  room,  or  an  an¬ 
nual  festival  may  be  taken  place  on  a  university  campus). 

6This  refers  to  the  owl :  ObjectProperty  property 


In  order  to  make  statements  about  some  events  that  are 
currently  associated  with  a  particular  place,  we  introduce 
an  additional  object  property  called  hasEventHappening- 
Now.  The  domain  and  range  of  this  property  are  of  the  class 
Place  and  the  class  EventHappeningNow,  respectively.  The 
EventHappeningNow  class  represents  a  set  of  all  events  that 
are  currently  taking  place  (details  of  this  class  is  discussed 
in  Section  5.4). 


Figure  3:  A  partial  ontology  definition  of  the 
AtomicPlace  &  CompoundPlace  classes  in  OWL/XML 
syntax 

5.1.1  AtomicPlace 

From  the  list  of  concrete  physical  locations  that  we  have 


mentioned  (i.e.,  campus,  building,  room,  hallway,  stairway, 
etc.),  some  of  these  locations  usually  do  not  contain  (spa¬ 
tially  subsume)  other  physical  locations.  For  example,  hall¬ 
ways,  stairways  and  rooms  in  a  building  usually  are  not  usu¬ 
ally  considered  to  be  a  type  of  physical  place  that  contains 
other  places. 

For  this  reason,  we  introduce  an  abstract  class  called 
AtomicPlace  to  represent  a  set  of  all  physical  places  that 
do  not  contain  other  physical  places.  This  class  in¬ 
herits  all  properties  from  its  superclass  Place.  How¬ 
ever,  it  puts  restrictions  on  the  range  of  the  two  proper¬ 
ties  spatiallySubsumes  and  isSpatiallySubsumedBy.  In 
this  AtomicPlace  class,  the  cardinality  of  the  property 
spatiallySubsumes  is  0,  indicating  all  instances  of  this  class 
do  not  contain  any  other  physical  places.  On  the  other 
hand,  the  range  of  the  property  isSpatiallySubsumedBy  is 
restricted  to  the  class  CompoundPlace,  which  is  a  subclass 
of  Place.  This  CompoundPlace  class  represents  all  physi¬ 
cal  places  that  may  contain  other  physical  places.  Figure  3 
shows  partial  representation  of  these  classes  in  OWL/XML 
syntax. 

Some  subclasses  of  the  AtomicPlace  class  include  Room, 
Hallway,  Stairway,  Restroom,  LadiesRoom,  MensRoom  and 
ParkingLot. 

5.1.2  CompoundPlace 

The  AtomicPlace  class  represents  a  set  of  places  that  con¬ 
tains  zero  number  of  Place  instances,  the  CompoundPlace 
class  represent  places  that  contain  at  least  one  Place  in¬ 
stances.  This  class  is  also  a  subclass  of  Place. 

Being  a  subclass  of  the  Place  class,  CompoundPlace  inher¬ 
its  all  properties  from  its  parent  class.  In  order  to  express 
all  instances  of  the  CompoundPlace  class  should  only  be  spa¬ 
tially  subsumed  by  instances  of  other  CompoundPlace,  the 
range  of  this  class’s  property  isSpatiallySubsumedBy  is  re¬ 
stricted  to  have  class  type  CompoundPlace.  This  restriction 
excludes  all  instances  of  the  CompoundPlace  class  to  be  spa¬ 
tially  subsumed  by  instances  of  the  AtomicPlace. 

5.2  Agents 

The  agent  class  in  CoBrA  represents  both  humans  agents 
and  software  agents.  Human  agents  are  users  in  an  intel¬ 
ligent  space.  Software  agents,  on  the  other  hand,  are  au¬ 
tonomous  computing  entities  that  provide  services  to  users 
(either  directly  or  indirectly)  in  an  associated  space. 

All  agents  have  associated  properties  that  describes  their 
contact  information,  which  includes  uniquely  identifiable 
names,  URLs  for  their  home  pages,  and  email  addresses.  In 
addition,  agents  are  assumed  to  have  certain  roles  in  differ¬ 
ent  events  and  activities  (e.g.,  a  person  can  have  the  speaker 
role  in  a  presentation  event,  and  device  agents  in  the  close 
vicinity  may  take  on  the  presentation  assistant  role  during 
the  presentation  session).  Different  roles  may  give  rise  to 
different  desires  and  intentions  of  an  agent. 

In  the  CoBrA  ontology,  the  notions  of  desire  and  intention 
are  both  associated  with  actions7.  Specifically,  the  notion 
of  desire  is  defined  as  an  agent’s  desire  for  some  actions  to 
be  achieved  by  other  agents  (e.g.,  a  person  with  the  speaker 
role  may  desire  some  service  agents  to  dim  the  lights  when 
his  presentation  starts),  and  the  notion  of  intention  is  de- 

7the  semantics  of  an  action  is  not  formal  defined  in  the  cur¬ 
rent  version  of  the  ontology.  In  v0.2,  all  instances  of  actions 
are  assumed  to  be  atomic. 


fined  as  an  agent’s  commitment  to  perform  some  particular 
actions  (e.g.,  a  person  with  the  audience  role  may  intend  to 
download  a  copy  of  the  slides  after  attending  a  presentation 
event). 

To  begin  our  ontology  modeling  for  agents,  we  introduce  a 
general  class  called  Agent,  which  is  a  set  of  all  human  agents 
and  computational  agents.  We  define  the  class  Person  to 
represent  human  agents  and  the  class  Sof  twareAgent  to  rep¬ 
resent  computational  agents  (both  of  which  are  subclasses  of 
the  Agent  class  and  disjoints  with  each  other).  All  agents  in 
our  ontology  are  associated  with  properties  that  describe 
their  contact  information.  To  generalize  properties  that 
serve  as  descriptions  of  contact  information,  we  define  an 
object  property  called  hasContactlnf ormation.  From  this 
property,  we  further  define  sub-properties  of  contact  infor¬ 
mation,  which  consist  of  hasFullName,  hasEmail,  hasHome- 
Page  and  hasAgentAddress. 

5.2.1  Role 

In  our  ontology,  the  class  Role  represents  a  set  of  all  roles 
that  can  be  associated  with  an  agent.  In  other  words,  it 
is  an  abstract  class  that  generalizes  all  possible  types  of 
agent  roles  in  the  CoBrA  ontology.  In  v0.2  of  the  ontol¬ 
ogy,  pre-defined  subclasses  of  Role  consist  of  SpeakerRole 
and  AudienceRole. 

To  associate  roles  with  an  agent,  the  object  properties 
fillsRole  and  isFilledBy  are  defined.  In  the  context  of 
the  OWL  language,  these  two  properties  are  inverse  property 
of  each  other  fillsRole  has  domain  Agent  and  range  Role, 
and  isFilledBy  has  domain  Role  and  range  Agent. 


Figure  4:  This  is  a  partial  definition  of  the  concepts 
related  to  roles,  intentions  and  desires  in  an  intelli¬ 
gent  meeting  room  system. 


5.2.2  Intentional  Actions 

All  actions  in  CoBrA  are  defined  as  instances  of  the  class 
IntentionalAction.  Informally,  intentional  actions  are  ac¬ 
tions  that  an  agent  performs  intentionally  and  with  certain 
goals  in  mind.  In  our  design,  we  assume  domain  applica¬ 
tions  will  extend  this  class  to  define  specialized  subclasses 
and  instances.  To  support  the  construction  of  intelligent 
meeting  room  systems,  we  have  pre-defined  a  set  of  con¬ 
crete  instances  of  IntentionalAction  that  are  common  in 
presentation  events  (see  Figure  4). 

All  instances  of  the  IntentionalAction  class  (or  its  sub- 


classes)  can  be  associated  with  either  an  instance  of  the  Role 
class  or  the  Agent  class  through  object  properties  intends- 
ToPerform  or  desiresSomeoneToAchieve.  The  domain  of 
these  two  properties  are  defined  to  be  a  union  of  the  class 
Role  and  Agent  (see  Figure  4). 

5.3  Agent’s  Location  Context 

In  the  last  two  sections,  we  have  described  a  set  of  CoBrA 
ontology  concepts  for  physical  locations  and  agents.  In  this 
section,  we  will  discuss  additional  concepts  for  modeling  the 
location  context  of  agents. 

By  location  context,  we  mean  a  collection  of  dynamic 
knowledge  that  describes  the  location  of  an  agent.  In  the 
context  of  the  OWL  language,  this  knowledge  is  a  collection 
of  RDF  statements  that  describe  the  location  property  of 
an  agent.  To  model  the  location  property  of  an  agent,  we 
introduce  an  object  property  called  locatedln,  which  has 
range  Place8. 

Physical  locations,  as  we  have  discussed  previously  in  Sec¬ 
tion  5.1,  are  categorized  into  two  distinctive  classes  namely 
AtomicPlace  (e.g.,  hallways  and  rooms)  and  CompoundPlace 
(e.g.,  campus  and  building).  Following  the  semantics  of 
these  two  classes,  no  agent  can  locate  in  two  different  atomic 
places  at  the  same  time,  but  any  agent  can  locate  in  two  or 
more  compound  places  at  the  same  time.  In  the  context  of 
the  OWL  language,  any  two  instances  of  the  AtomicPlace 
class  are  different  if  and  only  if  both  instances  have  distinc¬ 
tive  object  values9  for  the  same  class  property. 

To  capture  the  notion  an  agent  can  be  in  an  atomic  and 
a  compound  place,  from  the  locatedln  property  we  de¬ 
fine  two  sub-properties  called  locatedlnAtomicPlace  and 
locatedlnCompoundPlace.  The  former  restricts  its  range  to 
the  AtomicPlace  class,  and  the  latter  restricts  its  range  to 
the  CompoundPlace  class.  From  these  two  properties,  we 
can  define  additional  properties  that  further  restricts  the 
type  of  physical  place  an  agent  is  located  in.  For  exam¬ 
ple,  locatedlnRoom,  locatedlnRestroom  and  locatedln- 
ParkingLot  are  sub-properties  of  locatedlnAtomicPlace; 
locatedlnCampus  and  locatedlnBuiding  are  sub- properties 
of  locatedlnCompoundPlace. 

Since  all  agents  in  CoBrA  are  associated  with  different 
types  of  location  properties,  we  can  generalize  subsets  of 
these  agents  in  according  to  their  location  properties.  To 
do  so,  we  define  PersonlnBuilding  and  SoftwareAgentln- 
Building  to  represent  a  set  of  people  and  software  agents 
who  are  located  in  a  building,  respectively.  The  complement 
of  these  classes  are  PersonNotlnBuilding  and  Software- 
AgentNotlnBuilding. 

5.4  Agent’s  Activity  Context 

An  agent’s  activity  context  is  similar  to  its  location  con¬ 
text  -  a  collection  of  dynamic  knowledge  about  certain  as¬ 
pects  of  an  agent’s  situational  condition.  While  location 
context  describes  the  location  at  which  the  agent  is  situ¬ 
ated,  activity  context  describes  activities  in  which  the  agent 
participates.  In  the  current  version  of  the  ontology,  the  no¬ 
tion  of  an  activity  is  restricted  to  represent  a  set  of  all  typical 
group  activity  events  in  a  meeting  room  (meeting,  presen¬ 


8The  domain  of  this  property  is  owl: Thing,  indicating  any 
thing  may  be  located  in  some  physical  place. 

9an  object  value  refers  to  the  object  in  an  N-triple  statement 

(i.e.  (<subject>,  <predicate>,  <object>) 


tation  and  discussion)10. 

Activity  events  are  assumed  have  schedules.  For  presenta¬ 
tion  events,  we  have  defined  PresentationSchedule  class  to 
represent  their  schedules.  Presentation  schedules  are  defined 
to  have  startTime,  endTime  and  location  properties,  and 
each  of  which  respectively  represents  the  start  time  of  a  pre¬ 
sentation,  the  end  time  of  a  presentation  and  the  location 
of  a  presentation  event.  Each  presentation  event  has  one 
or  more  invited  speaker  and  an  audience.  These  two  con¬ 
cepts  are  defined  using  the  invitedSpeaker  and  expected- 
Audience  properties.  In  addition  to  start  time,  end  time 
and  location,  the  schedule  of  a  presentation  usually  includes 
a  title  and  an  abstract  of  the  presentations.  To  model 
these  two  concepts,  we  introduce  presentationTitle  and 
presentationAbstract  properties. 

An  agent’s  activity  context  is  usually  associated  with  ac¬ 
tivity  events  that  are  currently  happening.  For  example,  the 
activity  context  of  a  speaker  includes  the  presentation  event 
that  he/she  is  giving  the  presentation  at.  To  model  this,  we 
introduce  the  PresentationEventHappeningNow  class.  This 
class  is  a  subclass  of  the  EventHappeningNow  class  which 
models  an  event  with  the  time  predicate  “now” . 

For  a  presentation  that  is  currently  happening,  we  can 
specialize  the  type  of  rooms  at  which  the  event  takes 
place.  For  example,  a  room  that  has  an  ongoing  pre¬ 
sentation  event  is  defined  as  RoomHasPresentationEvent- 
HappeningNow,  which  is  a  subclass  of  Room  and  restricts  the 
range  of  its  hasEventHappeningNow  property  to  the  class 
PresentationSchedule.  In  addition,  we  can  also  specialize 
people  who  has  various  roles  in  an  on-going  event.  For  ex¬ 
ample,  a  set  of  all  people  who  have  the  speaker  role  of  some 
on-going  presentation  event  is  defined  as  the  SpeakerOf- 
PresentationHappeningNow  class.  Similarly,  we  define  the 
AudienceOfPresentationHappeningNow  class  to  represent  a 
set  of  all  people  who  have  the  audience  role  of  some  on-going 
presentation  event. 

6.  A  PROTOTYPE  SYSTEM  DESIGN 

In  the  last  section,  we  have  describe  the  key  concepts  in 
the  CoBrA  ontology.  In  this  section,  we  present  a  prototype 
system  design  for  realizing  the  intelligent  meeting  room  sce¬ 
nario  that  we  have  described  in  Section  4.1. 

In  our  prototype  design  (see  Figure  5),  there  are  five  ma¬ 
jor  system  components:  (i)  a  context  broker,  (ii)  a  personal 
agent  of  the  user,  (iii)  a  projector  agent,  (iv)  a  Bluetooth- 
enabled  cell  phone  that  the  user  carries,  and  (v)  devices 
and  clothes  tagged  with  RFID  tags.  The  context  broker, 
the  personal  agent,  and  the  projector  agent  will  be  imple¬ 
mented  using  the  JADE  agent  development  framework  [1], 
a  FIPA  compliant  Java  agent  development  library.  These 
agents  will  communicate  with  each  other  using  the  standard 
FIPA-ACL.  When  these  agents  communicate  for  the  pur¬ 
pose  of  sharing  context  knowledge,  the  OWL  language  will 
be  used  as  the  content  language  for  encoding  context  knowl¬ 
edge.  Because  all  agents  in  CoBrA  are  assumed  to  share  a 
common  ontology  (i.e.,  CoBrA  ontology)  for  representing 
context  knowledge,  both  the  projector  agent  and  the  per¬ 
sonal  agent  can  interoperate  with  the  context  broker  even  if 
their  internal  implementations  are  independently  designed 

10In  v0.2  of  the  ontology,  we  have  only  included  concepts 
related  to  presentation  events.  In  the  future  version,  we  will 
extend  the  ontology  to  includes  other  activity  events 


Figure  5:  In  our  prototype  system,  the  context 
broker  will  operate  on  a  MOCHA  PC,  an  all-in- 
one  design  mini  book-size  PC.  It  will  be  integrated 
with  Bluetooth  wireless  communication  and  RFID 
readers  for  detecting  people  presence.  The  broker 
will  communicate  with  software  agents  via  FIPA- 
ACL/OWL. 


(i.e.,  the  interoperability  of  these  agents  are  not  completely 
pre-defined  but  rather  achieved  through  ontology  sharing). 

In  addition  to  the  agents,  our  design  also  includes  the 
use  of  a  SonyEricsson  T68i  cell  phone,  which  is  component 
(iv).  On  this  Bluetooth-enabled  cell  phone,  users  will  store 
their  personal  policies  (e.g.,  similar  to  the  policy  described 
in  Section  4.1).  As  users  enter  the  meeting  room,  they 
will  submit  their  personal  policies  to  the  broker  through 
Bluetooth  networks.  These  policies  will  be  expressed  us¬ 
ing  the  XML/OWL  language  syntax  following  the  CoBrA 
ontology11. 

In  order  to  detect  the  presence  of  users,  we  will  label 
user  devices  and  clothing  with  RFID  tags,  similar  to  the 
approach  used  in  the  CoolAgent  RS  [4]  system.  We  are 
planning  to  deploy  a  number  of  RFID  readers  in  our  pro¬ 
totype  environment,  for  example,  placing  readers  next  to 
the  meeting  room’s  door  and  underneath  the  tables  in  the 
meeting  room. 

7.  RELATED  WORK 

Our  work  is  closely  related  to  other  pervasive  and  context- 
aware  computing  research  such  as  Intelligent  Room,  Context 
Toolkit,  Cooltown,  One. World  [8]  and  Centaurus  [11].  In 
comparison  to  the  previous  systems,  our  design  of  the  Con¬ 
text  Broker  Architecture  takes  a  knowledge  representation 
approach  to  build  ontologies  of  contexts  and  attempts  to  use 
Semantic  Web  language  (i.e.,  OWL)  as  the  content  language 
in  agent  communication. 

An  explicit  representation  of  context  ontologies  distin¬ 
guishes  CoBrA  from  other  context-aware  systems.  While 
the  previous  systems  rely  on  ad  hoc  representations  of  con¬ 
texts  to  exchange  information,  CoBrA  takes  a  knowledge 
representation  approach  allowing  context  knowledge  to  be 
reasoned  and  shared  through  a  well-defined  ontology  model. 

As  in  other  systems  (e.g.,  Context  Toolkit  and  Cooltown), 
the  CoBrA  ontology  models  concepts  for  describing  user  lo- 

nIn  the  next  version  of  the  CoBrA  ontology  (v0.3),  we  will 
use  concepts  from  the  policy  language  REI  [10] 


cations.  These  concepts  are  useful  for  guiding  the  decision 
making  of  context-aware  applications  [16,  5,  11].  Neverthe¬ 
less,  none  of  the  previous  systems  have  explored  the  space 
and  spatial  relationship  aspects  of  the  location  contexts  (i.e., 
information  that  describes  the  whole  physical  space  that  sur¬ 
rounds  a  particular  location  and  its  relationship  to  other 
locations).  Modeling  space  and  spatial  relationships  are  im¬ 
portant  in  CoBrA.  We  currently  have  a  simple  model  of 
space  and  spatial  relationships  (see  Section  5.1).  In  the 
DAML+OIL  community,  recent  discussions  on  the  daml- 
spatial  mailing  list  have  initiated  the  work  to  develop  a  Se¬ 
mantic  Web  version  of  the  spatial  ontology  based  the  SUO 

[14]  and  Cyc  [6].  In  the  future,  we  plan  on  using,  if  possible, 
or  at  least  mapping  to,  if  feasible,  one  of  these  consensus 
ontologies  for  space. 

In  addition  to  using  OWL  as  an  ontology  language  for 
modeling  contexts,  we  also  attempt  to  use  OWL  as  the  con¬ 
tent  language  in  agent  communication.  Our  approach  is 
similar  to  the  use  of  OWL  in  the  TAGA  system  (Travel 
Agent  Game  in  Agentcities)  [22].  In  TAGA,  collections  of 
agent  communication  primitives  (e.g.,  action,  result,  query, 
sender,  and  receiver)  are  defined  using  OWL,  forming  on¬ 
tologies  for  agent  communications12.  Using  these  ontolo¬ 
gies,  agents  can  express  their  reasons  for  communicating 
with  other  agents  (i.e.,  making  propositions  and  querying 
for  information). 

Using  OWL  as  the  content  language  in  agent  communica¬ 
tion  will  allow  the  underlying  agent  implementations  to  be 
better  integrated  with  Semantic  Web  technologies  (e.g.,  on¬ 
tology  inference  engines  and  Semantic  Web  query  languages 
[7]).  In  contrast  to  the  use  of  other  content  languages  such 
FIPA-SL,  KIF  and  XML,  the  use  of  OWL  as  a  content  lan¬ 
guage  helps  to  simplify  the  underlying  implementations  for 
composing  communication  messages  (e.g.,  avoiding  multi¬ 
level  parsing  implementations  for  translating  contents  into 
internal  knowledge  representation). 

8.  CONCLUSION  AND  FUTURE  WORK 

Computing  is  moving  towards  pervasive,  context-aware, 
environments  in  which  resource-limited  agents  will  require 
external  supports  to  help  them  to  become  aware  of  their  con¬ 
texts.  The  Context  Broker  Architecture  described  in  this  pa¬ 
per  will  help  these  agents  to  acquire,  reason,  and  share  con¬ 
textual  knowledge.  A  key  component  of  this  infrastructure  is 
an  explicit  representation  of  context  ontologies  expressed  in 
the  OWL  language.  Without  this  ontology,  inconsistent  and 
ambiguous  context  knowledge  cannot  be  easily  detected  and 
resolved,  and  acquired  context  knowledge  cannot  be  shared 
with  independently  developed  agents. 

We  are  developing  an  OWL  reasoning  engine  called  F- 
OWL13  to  support  the  use  case  described  in  Section  4.1. 
This  reasoning  engine  is  implemented  using  Flora-2  in  XSB 

[15] ,  an  object-oriented  knowledge  base  language  and  appli¬ 
cation  development  platform  that  translates  a  unified  lan¬ 
guage  of  F-logic,  HiLog,  and  Transaction  Logic  into  the  XSB 
deductive  engine  [21]. 

We  plan  to  prototype  an  intelligent  context  broker  and 
integrate  this  broker  with  the  Centaurus  systems  (a  frame¬ 
work  for  building  pervasive  computing  services  developed 

12FIPA  OWL  content  language  ontology  is  available  at  http : 
//taga.umbc . edu/taga2/owl/f ipaowl . owl 
13F-OWL  web  site:  http : //umbc  .  edu/~hchen4/f  owl/ 


at  UMBC)  [11].  The  objective  is  to  create  a  pervasive 
context-aware  meeting  room  in  the  newly  constructed  In¬ 
formation  Technology  and  Engineering  Building  on  UMBC’s 
main  campus14. 
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